Thanks for the PR!

In general, I prefer to keep workarounds as close to the source of the problem as possible. In this case, we're compensating for the shortcomings of the Parameters<T> type. I'm curious if any of the workarounds in microsoft/TypeScript#32164 like microsoft/TypeScript#32164 (comment) could be used for this?

Hi @Methuselah96,

Thanks for sharing the workarounds. I created a TypeScript playground to show that the solution proposed in this PR is as safe as the current solution and also provides intellisense as function overloads. On top of that Parameters<Color['set']> (rest in this example) would resolve all parameters, which is beneficial to all type consumers.
The reason why I refrain from the workaround is that we would need to apply that to not only Color['set'] but essentially all props, I guess we'd run into edge cases with this hard to maintain type in no time.

Yeah, makes sense, I assume we would only be doing this for any overloaded set functions?

I'm probably okay with this as long as this pattern doesn't need be to used too much, and with the understanding if any downsides emerge down the road that we're likely to go back to using overloads.

Yeah, makes sense, I assume we would only be doing this for any overloaded set functions?

That would make sense, although I'm not aware of other ones. At least this is the one with the largest impact on our user side.

I'm probably okay with this as long as this pattern doesn't need be to used too much, and with the understanding if any downsides emerge down the road that we're likely to go back to using overloads.

Absolutely. If any downsides emerge, I'm all for reverting.

Thanks for considering! I'll mark this ready for review then.

Thanks! This will get released with r157 at the end of the month.

cc @CodyJasonBennett This might be useful for @react-three/fiber, but I guess can't be depended on until R3F requires @types/[email protected] or later.

Thanks for looking out. Yeah, we worked around this already, but I'm happy to review any related work in the future.

Hey @CodyJasonBennett, sorry, didn't want to blindside you. Is there a blocker for this from the R3F side? I guess this is also beneficial for you.

No blocker, I've worked around this in pmndrs/react-three-fiber#2931 and pmndrs/react-three-fiber#2932 (the v9 branch may be easier to follow for further inspection). We rely heavily on inference, moreso in v9 also which is strictly for types/internal tests.

The linked workarounds from TS triage don't work very well since they can create complex unions that fail from complexity. What you can do alternatively to this PR, while still providing overloads, is follow overloads with a mixed signature that reflects the implementation:

set(r: number, g: number, b: number): this;
set(color: ColorRepresentation): this;
set(...args: [color: ColorRepresentation] | [r: number, g: number, b: number]): this;

Parameters always takes the last signature, so this should still play nice if this would be preferable to author. This goes for constructor signatures also.